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ABSTRACT 


MITRE has designed and installed a prototype coaxial cable bus 
commuP!.,ations system at NASA's Johnson Space Center to support the 
Trend Monitoring System (TMS). The communications facility will be 
maintained by contractors under NASA's supervision. This document 
describes troubleshooting procedures at the system level; the procedures 
can be used by repair personnel to isolate a fault in the TMS and to 
restore the system to operation by swapping out failed components. 
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DIAGNOSTIC PROCEDURES 
FOR 

TREND MONITORING SYSTEM (TMS) COMMUNICATIONS 


SECTION I 
INfivODUCTION 


L 0 BACKGROUND 

At NASA's Johnson Space Center (JSC) in Houston, Texas, the 
Institutional Data Systems Division (I DSD) provides data reduction support 
to manned spaceflight missions. The process of data reduction is accomplished 
principally by the Orbiter Data Reduction Complex (ODRC) at present. 

In response to requests from engineers both at NASA installations and at 
principal contractor locations, data are extracted from raw data tapes, 
converted to engineering units, and displayed in any one of a number of 
different output forms. Ordinarily, the data reduction support offered by 
the ODRC occurs at times ranging from hours to days after data arrives at 
JSC. 

In 1977, however, as dat^ processing requirements for the test 
program of the Space Shuttle were analyzed, it became clear that because 
of the inability to test all thermal responses of the Shuttle before the 
missions, there exists a need to monitor certain thermal measurements in 
near real time. An interactive system in which thermal data are to be made 
available as soon as possible after data tapes arrive was therefore planned. 

To meet this requirement, NASA personnel in IDSD's Engineering 
and Special Development Branch (FD7) designed and implemented the Trend 
Monitoring System (TMS). The TMS employs MEGATEK 5000 intelligent 
graphics terminals and a MODCOMP IV/35 host minicoraputer . Because 
high data rates are required in the system (a typical plot request may 
generate 25,000 bytes of response which must be displayed in under 
5 seconds) and because the separation between the host and the terminals 
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is great, conventional communications systems are costly and difficult to 
apply. MITRE had developed a coaxial->cable-based bus communications 
system which supports high data rates over separations of several miles [1], 
and NASA elected to install a prototype bus system both to support the TMS 
and to provide a test bed for analysis of the bus concept . 

In the installation of the bus system, MITRE performed system 
engineering of the cable plant and developed custom interfaces between the 
TMS computers and the bus. This work is documented in a series of reports 

([2], [3], U], [5], [6], [7], [8]). 

1.1 Overview of Report 

An important aspect of the operation of the bus communications 
system to support the TMS is timely diagnosis and repair of failures in the 
system. This document gives guidelines for isolation of faults and describes 
how to remedy problems by substituting spare components for failed units. 
The report is intended to be used as a manual during correction of operating 
problems. Section II contains a series of procedures which should enable 
a problem to be isolated and corrected usually in less than an hour. 

Section III contains limited material describing fault isolation within a 
malfunctioning Bus Interface Unit (BIU); this type of maintenance should be 
done after the system has been restored to full operation by substitution of 
a spare unit. The material in Sections II and III applies to remedial 
mainte.nance, but Appendix I contains information on how to use statistics 
from bus operation to detect incipient problems. Appendix II contains a 
listing and Nassi-Shneiderman chart of the VOLLEY program used in 
isolating cable plant faults. 
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SECTION II 

SYSTEM FAULT ISOLATION 


2.0 INTRODUCTION 


In the fault isolation discussed in the following paragraphs, it is 
assumed that software failures occur rarely enough that they can be cured 
by rebooting with new copies of the same software. This diagnostic procedure 
does not attempt to identify problems that may arise because of software 
design or implementation errors, but rather concerns itself solely with 
hardware failures and software failures which arise from contamination of 
the program by an unintended modification of the code. 

Failures which can cause interruptions in TMS communications 
can occur at nine possible sites in the system. These sites are listed 
in Figure 2.0-1, together with identifying numbers which are used in the 
diagnostic procedures in paragraph 2.1. 


Site 

Number Site 


1 

2 

3 

4 

5 

6 

7 

8 
9 


MODCOMP software 

MODCOMP hardware 

MODCOMP 4805 board bus 
interface hardware 

MODCOMP BIU 

Radio Frequency (RF) cable 
plant 

MEGATEK BIU 

NOVA 4040 board bus interface 
hardware 

NOVA software 

NOVA hardware 


Figure 2.0-1 Communications Failure Sites in the TMS 
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There are a number of diagnostic approaches and tools which can 
be used to localize faults in the TMS communications system. Among these 
are the basic method of substituting known good (spare) components for 
suspected bad components, after observation of system behavior or use of 
special purpose tools has isolated the probable failure area. Among the 
special purpose tools which are mentioned in the following paragraphs are a 
backboard test BIU, which reflects back to the sender any message sent to 
it, a MODCOMP program (VOLLEY), which sends out periodic messages to the 
backboard BIU and examines the replies, and a dummy cable system (test jig), 
which can be substituted for the real cable plant during cenain tests . 

2.1 Fault Diagnosis Procedures 

Procedures for diagnosis of TMS communications problems are 
shown in Figures 2.2-1 through 2.1-7 and Figure 2.1-9. Figure 2.1-8 
describes a cable system test jig, and Figure 2.1-10 is a schematic diagram 
of the TMS cable. Diagnostic work should begin by following the steps of 
Procedure A (Figure 2.1-1). 

The procedures in this section are intended to be used step-by-step 
for isolating problems and for correcting them by substituting components . 
Detailed instructions on the repair of failed components is beyond the scope 
of this manual, though a limited suggestion of an approach to the repair 
of BIUs is found in Section l il. 

The TMS Operator's Guide [ 9 ] and the TMS User's Guide [10] 
should be available for reference during use of these procedures. These 
two documents give details of such procedures as booting the MODCOMP 
and booting the terminals. 
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Reboot the affected) 
terminal - watch 
red and green 
lights or. affected 
BIU 



Failure is probably] 
at site 6, 7 > 8, or 9 

Perform procedure 
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Figure 2.1-1 Top Level Diagnosis Procedure 
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Quick check of the affected terminal ; 

a. Verify that power is on to the NOVA, to the display (note pilot 
light), to the hard copier, and to the BIU. 

b. Depress the black reset button on the terminal's hard copier. 

c. If the problem is in booting the terminal, verify that the BIU 
reset button is not depressed after the reset and pr load switches 
have been raised on the MEGATEK. 

2. Quick check of whether the MODCOMP appears to be ready and running ; 

a. Verify that all essential components have power. If trouble 
is found, correct the problem and reboot the MODCOMP. At 
least the following components should be checked: 

(1) MODCOMP BIU 

(2) MODCOMP Peripheral Controller Interface (PCI) cabinets 

(3) Cable system power supply 

(4) System console (must be on line as well as powered on) 

(5) MODCOMP disks (must be ready as well as powered on) 

b. Check that the MODCOMP run light on the CPU is lighted and that 
the console responds to a control-A input. 1'/ either or both 

of these conditions is not true, reboot the MODCOMP- 


Figure 2.1-2 Diagnostic Procedure A - Quick Check 
of User Terminal and of MODCOMP 
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Fiawe 2.1.4 Diagnostic Procedure C ~ Eliminates Sites 6, 7. 8, and 9 

(MEGATEK BIU, 4040 Board, NOVA Software and Hardware) 
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Figure 2.1-5 Diagnostic Procedure D - Eliminate Sites 5 and 6 
(Cable Plant and MEGATEtC BIU) 
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1. Turn off power to the BIU. 

2. Unplug power cord from the BIU and disconnect computer cable at 
the BIU. 

3. Move Programmable Read-Only Memory (PROM) chips from old BIU 
to new BIU, if necessary. NOTE ; When substituting BIUs at 
MEGATEKs, this step is normally not necessary. 

a. Remove top cover of BIU by taking out four attaching 
screws on botton of unit . 

b. The PROMs are located at board coordinates U22 and R14 
(these are the locations of pin 1 of the chips). Carefully 
use a chip extraction tool to engage the chip and lift 
straight up, taking care not to bend the pins . 

c. Carefully replace each chip in its corresponding location 
in the new BIU. Take care not to bend the pins during 
insertion. The PROM labeled F800 should go at coordinate 
U22 and the one marked FCOO at R14. The cutout on the 
top of the PROM should be toward the edge connector on 
the digital board. When the PROMs are properly inserted, 
there will be one unfilled pin socket at each end of each 
PROM. 

4. Move RF cables from old BIU to new BIU. The orange or red 
cable should be connected to the transmit modem (marked with 
a T on the back of the BIU), while the green or blue cable 
should be connected to the receive modem (marked with an R). 

5. Connect computer cable to the new BIU and connect the power 
cord to the new BIU. 

6. Turn on power to the new BIU. 


Figure 2.1-6 Diagnostic Procedure E - Method of 
Swapping BIUs 
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NOTE; This procedure cannot be performed during normal TMS operation. 


1 . Build or locate the bus test jig, which is constructed as follows: 

Two four-way multitaps (with 20 db attenuation to the 
tap — Jerrold FFT-4-20 or equivalent) are connected 
back-to-back using a connector such as Jerrold VHH. 

The pass-through outputs on each tap (see Figure 2.1-8) 
should be terminated with 75-ohm resistive terminators 
(such as the combination of Jerrold VSF-59A adapter and 
TR-75F terminator). The arrows embossed into the tap 
cases should point away from each other. Designate one 
of the taps as the transmit tap. 

2. Connect the MODCOMP BIU and the backboard diagnostic BIU 
to the test jig by cabling the transmit modem of each BIU to the 
transmit tap and the receive modem to the other tap. (Note 

that any TMS BIU may be used as a backboard BIU if Procedure E 
(Figure 2.1-6) is followed to place the backboard PROMs into 
the BIU.) 

3. At the MODCOMP console, initiate the bus test program VOLLEY 
by the following steps: 

a. Get the MODCOMP's attention by typing 
control-A 

b. Enter /VOLLEY/E (carriage return) 

4. VOLLEY will then begin to write messages to the line printer. If 
the message BACKBOARD IS OKAY; hh:mm:ss.ttt mm/dd/yyyy 
appears, the TMS problem is in the cable plant (site 5). If other 
messages appear, the problem is in MODCOMP hardware (site 2) 
which affects writing to the bus . 

5. Remove the VOLLEY program by getting the MODCOMP's attention 
and then entering /VOLLEY/K (carriage return). 

Figure 2.1-7 Diagnostic Procedure F - Distinguishes between Sites 2 and 5 
(MODCOMP Hardware and Cable Plant) 
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Figure 2.1-8 Structure of Bus Test Jig 




NOTE; Steps 1 and 2 of this procedure can be performed concurrently with 

regular TMS work if a portion of the cable sy .em is still operational. 

1 . Perform a quick check of the bus system power supply at the headend 
(located in one of the MODCOMP cabinets). 

a. Check that the power supply is receiving 115 VAC where it 
is plugged into the MODCOMP rack. 

b. Check the current in the secondary of the power supply, 
if the power supply in use is equipped with a meter. 

The current should read about 1.7 Amperes when the 
supply is powering the 6 line extender amplifiers used 
in the TMS system. If no meter is available, check the 
indicator light on the bottom of the supply. If the current 
is substantially different or if the indicator light is out, 
check the two fuses in the power combiner at the back of 
the cable system headend . Any fuse value greater than 3 A 
and less than 15 A may be used in the TMS , though the 3 A 
fuse should be used if possible. 

2. Use the MODCOMP test program VOLLEY to isolate the location of 
cable bus failure by following the steps given below. The locations 
referenced in the steps are keyed to the schematic diagram of the 
cable system shown in Figure 2.1-10 (more information about 

the cable system is found in [2]). 

In each of the steps below, first connect the backboard BIU 
(any BIU with the diagnostic backboard PROMs in it) to the 
cable system at the indicated test point; the transmit cable 
from the backboard should go to the odd-numbered point 
(orange-banded cable) and the receive cable to the even- 
numbered point (green-banded cable). The VOLLEY program 
should then be run as described in steps 3,4, and 5 of 
Diagnostic Procedure F (Figure 2.1-7). If the VOLLEY program 

Figure 2.1-9 Diagnostic Procedure G - Isolates and Eliminates Failures 
within Site 5 (Cable Plant) 


13 



is successful, the cable plant is operational between the headend 
and the test point being checked. 

For ease in checking, conduct the tests in the following manner: 

(1) Points 1 and 2 (the only taps in Building 30) 

(2) If points 1 and 2 were operational, test points 11 and 12 

(3) If points 11 and 12 were operational, test all points within 
Room 306B of Building 45 

(4) If points 1 and 2 were operational, but points 11 and 12 
were not operational, test all points within the utility 
tunnels 

3. When the failed portion of the system has been isolated, bus 
communications should be restored by the following means . 

(The portion containing the failure may include multitaps , line 
amplifiers, and/or directional couplers, as well as cable and 
connectors. Repairs of these components are discussed in the 
following steps.] 

NOTE : POWER TO THE CABLE SYSTEM MUST BE OFF 
BEFORE ANY OF THE FOLLOWING STEPS ARE 
TAKEN. 

a. Check connections to the cable at suspected problem points. 
Make certain that the center conductor is firmly grasped by 
the set screw in all box-type components and that the braid 
or shield of the cable is firmly grasped by the connector. 

b. If the failed component is a multitap, replace it with a 

spare of the same value; tap values are shown in Figure 2.1-10. 
Note that the shell of the tap can remain in place and only the 
internal portion substituted. If a tap has failed such that 
it affects only terminals connected to it , the tap may be left 

Figure 2.1-5 (Continued) 
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in place and the terminals connected to another convenient set 
of taps . The transmit and receive cables of a terminal should 
normally be connected to taps in the same pair (as shown in 
Figure 2.1-10). 

c. If the failed component is a line extender amplifier, replace the 
internal amplifier unit (leave the shell in place) and realign the 
amplifier using the procedure given in [2]. Make certain that 
the amplifier power tap is on the 45-60 V range. 

d. If the failed component is a directional coupler, replace the 
interior part of the directional coupler (leave the shell in place) 
with a coupler of the same isolation (as shown in Figure 2.1-10). 

e. In the unlikely event that the failure is found to be an actual open 
or short in the cable itself, either the entire cable piece which hao 
failed can be replaced, or the damaged area can be cut out and a 
new piece spliced in. Location of the exact point of a cable break 
is beyond the scope of this report, but such failures are expected 
to occur only at points of physical damage (cutting, etc.) to the 
cable. If the cable must be spliced, a box splice (such as Jerrold 
PBA series) should be used to facilitate later testing of the 
splice. In installing any new cable, make certain that connections 
are performed as in step a. above so that both the braid and the 
center conductor are electrically continuous . 


Figure 2.1-9 (Concluded) 
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SECTION III 

FAULT ISOLATION WITHIN BIUs 

3.0 INTRODUCTION 

Repair of Bus Interface Units should ordinarily be undertaken by 
qualified engineers or technicians who work from the schematic diagrams 
and explanations in [ 4 ] and [11] to troubleshoot the digital logic of the BIU. 

The BIU naturally falls into a modular division, however, and in many cases 
simple replacement of modules provides an easy way to isolate a problem . 
Operating experience has shown that the most likely components to fail in a 
BIU are logic chips on the digital board, the modular power supply, and 
circuitry (usually a chip) in either the modulator or the demodulator. The 
remainder of this section defines several steps that may be fruitful in dealing 
with BIU problems in these areas. 

3.1 Diagnosis of BIU Trouble 

As discussed in [ 4 ], the digital board of every TMS BIU is capable 
of supporting either a parallel interface or a serial interface, but the BIU case 
contains a connector for only one interface type. A BIU is termed a parallel 
or a serial BIU, consequently, according to the connector on the case. 

The blU's operation is, of course, defined by the Programmable Read-Only 
Memory (PROM) chips which are inserted into the digital board. Operationally, 
the circuitry of the BIU falls into a portion to support the parallel interface, 
a portion to support the serial interface, and a portion to support the BIU 
interface to the bus network. Some types of failures affect all three opeiational 
portions of the BIU, while others affect only one of the portions. 

The testing of the network and serial portions of a BIU can be done on 
the operational bus system without interfering with normal users, provided that 
an additional BIU (which must be a serial BIU with PROMs to support an 
asynchronous terminal) and a "dumb" terminal with RS-232 interface are 
available. The second BIU should be connected to the bus system (the transmit 
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modem [marked with a "T"] should be connected to the orange-labeled cable 
and the receive modem to the green-labeled cable), and the "dumb" terminal 
should be connected to the BIU's RS-232 plug. The red dual-inline-package 
(DIP) switch on the BIU digital board (see [ 4 ]) should be set *0 agree with 
the speed of the asynchronous serial terminal. The switch package is marked 
on one side w; h switch numbers, and on the other side with the word "open." 
Exactly one of the positions on the DIP switch should be depressed on the 
side with switch numbers; all the others should be depressed on the side 
marked "open." Table 3.1-1 shows the correspondence between switch 
positions and terminal speed. 

Table 3.1-1 

DIP Switch Settings for Asynchronous Serial Terminals 


Switch Position 
8 
7 
6 
5 
4 
3 
2 
1 


Speed (Baud) 
75 
150 

300 

600 

1200 

2400 

4800 

9600 


The test arrangement of the serial BIU and "dumb" terminal can be 
left connected to the network indefinitely (either powered on or not), if 
desired. 


Figure 3*1-1 shows a diagnostic procedure that can be used to 
isolate failed portions of a BIU. It should be noted that this procedure 
will not identify all possible problems, but has been designed to pinpoint 
quickly the most probable failures. 
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Perform a quick check for power in the BIU by first checking the 
fuse (next to the line cord plug) and power supply output voltages. 

If the power supply connector pins are numbered from right to left 
when viewed from the top front of the BIU, then the following 
voltages should be present: 


Pins 1,2 
3 


115 VAC 
-5 VDC 
-12 VDC 
+12 VDC 
return 
+5 VDC 


To isolate the failed portion of the malfunctioning BIU, perform the 

following tests: 

a. Install the backboard PROMs in the bad BIU and connect 
the BIU to the bus system. Connection of the BIU and 
insertion of the PROMs should be done as described in 
Diagnostic Procedure D (Figure 2.1-5). 

b. Press the reset button on the "dumb" terminal BIU, and 
answer the WHICH SYSTEM? query with BAC (followed by a 
carriage return). 

c. If LINK ACCEPTED appears at the 'duinb" terminal, type a 
string of 20 or so arbitrary characters (followed by a 
carriage return) and verify that the same string is echoed back 
from the backboard. If LINK A'^CEPTED does not appear or 
this test fails, go to step e. 


Figure 3.1-1 

Diagnostic Procedure for a Failed BIU 
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d. If this test is passed, then the most probable failure is a 
chip on the BIU digital board: 

(1) If the BIU is a serial BIU, the 1488, 1489, 
and 6850 chips are suspect. 

(2) If the BIU is a parallel BIU, the two 6522 
chips are suspect. 

In either case, the suspected chips should be replaced 
with known good chips. If the bad BIU is a parallel BIU, 
it should be retested with a MEGATEK (or with the MODCOMP); 
if it still does not work, repair attempts should be continued 
first by replacing other chips on the board, and then by 
digital logic checkout using the information in [4]. 

If the bad BIU is a serial BIU, it may be tested by swapping 
the backboard and "dumb” terminal BIUs in the test arrangement 
(using the procedure in Figure 2.1-6, and remember to swap 
the PROMs). If the bad BIU does not work then, continue to 
replace chips until all have been checked before beginning 
detailed logic checkout using [4]. 

e. If the bad BIU fails the backboard test of step c. above, turn 
off power to the BIU and substitute a known good digital board 
(move the backboard PROMs to the new board). Then retry 

the test of step c. If the test succeeds, the problem is probably 
a bad chip on the first digital board; chips should be replaced 
systematically before detailed logic checkout is begun (using 
information found in [4]). 

f. If substituting digital boards, as in step e. , does not correct 
the problem, substitute known good modems in the bad BIU. 


Figure 3.1-1 (Continued) 
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In performing this substitution, substitute modems in pairs only 
and make certain that the transmit modem (marked with a "T”) 
goes into the BIU slot marked with a *'T'* and that the receive 
modem (marked with and "R”) goes into the slot marked with an **R". 
REVERSING THE MODEM POSITIONS WILL DAMAGE THE 
M ODEMS . 

After substituting the modems, retry the test of step c. If the 
test succeeds, the problem lies in one of the modem boxes. 
Reference 10 may be used to assist in determining the exact 
failure . 

g. If the test of step f. fails, the problem most likely lies in the 
BIU power supply, though possibly there could be a connection 
failure in the BIU chassis. 


i 


f 

Figure 3.1-1 (Concluded) 
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APPENDIX I 

USING BUS STATISTICS TO DETECT INCIPIENT PROBLEMS 


1.0 INTRODUCTION 

Each Bus Interface Unit in the TMS emits periodic status messages 
onto the network; these status messages give information about successful 
and failed transmissions, number of received packets, and internal status 
information about the BIU. These messages are gathered from the network 
by the MODCOMP's BIU and accumulated by a part of the MODCOMP bus 
symbiont program described in [5]. 

Figure I-l shows a typical bus statistics printout; this type of listing 
can be obtained by following procedure M-2 of [8]. At the top right of the 
printout is the time when the statistics counts were last reset; if the counts 
have not been reset since the last time the MODCOMP was booted, this 
field will show all zeros. The method of resetting the fields is also 
documented in procedure M-2 of [ 8 ]. Resetting the counts occasionally is 
desirable because when they reach 65535, they are not further incremented. 

At the top right of the report are shown the time and date of the status 
summary. Below the date and time is a count of errors detected by the 
MODCOMP bus symbiont; these errors are usually generated when the 
MODCOMP BIU is reset or powered off and on. 

Two lines appear in the status report for each BIU yhich has been 
active on the network since the last reset of the statistics accumulators. 

The first line shows the contents of the last status message emitted by a BIU, 
while the second line gi /es a running total of the count fields. The first 
column of the report shows the network address (2 bytes) of a BIU; on the 
TMS system the addresses 0200 (TMS MODCOMP), 0100 (STCS MODCOMP), 
BBOO (backboard diagpcstic BIU), and 3x00 (terminals, where x is the 
terminal number) appear. 
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The "GOOD XMITS" column shows the number of successful trans- 
missions by a BIU, while "MISSING ACKS" indicates the number of times 
that the BIU transmitted a message but did not receive a correct acknowledgement. 
"COLLISIONS" counts the number of times that the BIU began transmitting 
at the same time that another BIU began to transmit. 

"LOST PKTS" shows how many network packets were discarded by the 
BIU because the recipient failed to acknowledge the packet k times, where k 
is the maximum number of retries. "GOOD RCVS" indicates how many 
packets have been successfully received, while "NOISY RCVS" shows how 
many packets have been received with a bad longitudinal parity. "CHOKED 
RCVS" counts the number of time that a packet arrived for the BIU, but the 
BIU's buffers were all full and the BIU responded with an 'Tm Full" 
acknowledgement. "LINE BUSY" tells the number of times that the BIU 
found the network in use when the BIU wanted to transmit a packet. 

The "QUEUES STATUS," "UARTS STATUS," and "OTHER STATUS" 
gives status words for various internal aspects of the BIU. The "TIME OF 
LAST UPDATE" shows the time stamp (added by the MODCOMP) when the last 
status message was received; BIUs in the TMS system emit status messages 
once each minute. At the right of the time of update is a 12-character field 
identifying the PROM being used in the BIU. 

1 .1 Warning Indicators in the Status Report 

In the vast majority of the time, the communications system will 
operate properly and the counts of missing acknowledgements, collisions, 
lost packets, noisy receives, choked receives, and line busy will be small. 
Certain conditions, however, can cause one or more of these counts to 
increase, and may indicate an imminent failure. Table 1 .1-1 shows several 
of the status report fields, together with screening criteria and an indication 
of what may possibly be wrong. It should be remembered, of course, that 
certain "normal" causes can produce the same types of indications; for 
example, powering off one BIU in a conversation will cause the other BIU 
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to report many missing acknowledgements and lost packets. The table 
should thus be used to help explain abnormal figures only when no obvious 
explanations are knows . 


Table l.l-I 

INDICATIONS FROM ABNORMAL STATISTICS REPORT FIELDS 
Indication Possible Problem 


Missing acknowledgements are 
more than 5% of good trans- 
missions or lost packets are 
more than about 0.01% of good 
transmissions 

Excessive line busy for one 
terminal (highest figure is 
more than twice next 
lowest figure) 

Choked receives more than 
about than about 1% of 
good receives 

Noisy receives greater than about 
1% of good receives 


Status message older than about 
3 minutes before time of 
status report 


May indicate failing modem in the 
BIU or in another BIU, or 
powered-off or unavailable 
recipient BIU 


May indicate malfunctioning 
receive modem 


May indicate a problem between 
the BIU and its subscriber 
computer or terminal 

May indicate unexplained noise 
on the network, possibly 
from improper or loose 
shielding on the RF drop 
cables 

May indicate malfunctioning BIU 
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APPENDIX II 

LOGIC DIAGRAM AND LISTING OF VOLLEY TEST PROGRAM 
USED IN DIAGNOSTIC PROCEDURE F 



The following diagram shows the logic flow of the program VOLLEY. 
Conventions used in this type of chart are described in [12], 


INITIALIZE AND WRITE START-UP MESSAGE 


DO FOREVER 


CLEAR USER FILE TABLE STATUS 


SELECT OUTPUT MESSAGE 


ISSUE QUICK-RETURN READ 


ISSUE QUICK RETURN WRITE OF MESSAGE 


DELAY 400 TICKS (2 OR 4 SECONDS, DEPENDI NG ON MODCOMP 

SYSGEN) 


\ WRITE COMPLETED? 


TERMINATE 


\ READ COMPLETED? 

/ 

\ WAS CORRECT ECHO/ 

TERMINATE 

y\ received 

READ 

OUTPUT 

OUTPUT 

OUTPUT 

SUCCESS 

ERROR 

ERROR 

MESSAGE 

MESSAGE 

MESSAGE 


OUTPUT ERROR 
MESSAGE 
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IV FORTRAN IV CO 04-16-79 ll:3BPA0E 1 

1 C THIS IS THE 'VOLLEY' TEST PROORAN. 

2 C 

3 C ITS PURPOSE 18 TO TEST REGULARLY TO SEE WHETHER THE BACKBOARD 

4 C BIU CAN BE DETECTED ON THE BUS. 

5 C IT 18 INTENDED TO AID IN FINDING FAULTS IN THE CABLE NETWORK. 

6 C IF ANY OTHER PROGRAM 18 ACCESSING THE BACKBOARD FROM THE 

7 C MODCOMP CONCURRENTLY WITH THIS ONE. RESULTS ARE UNPREDICTABLE. 

8 C 

9 C THIS PROGRAM IS INTENDED TO BE CATALOGED AS A STAND-ALONE TASK. 

10 C AS DISTINCT FROM A BATCH OVERLAY. THIS IS BECAUSE THIS PROGRAM 

11 C NEVER TERMINATES VOLUNTARILY. AND MUST ALWAYS BE ABORTED BY THE 

12 C SYSTEM OPERATOR. MODCOMP PROVIDES NO FACILITY TO CANCEL RUNAWAY 

13 C BATCH TASKS FROM THE BATCH INPUT FILE. 

14 C 

19 C HERE 18 HOW TO INVOKE THE PROGRAM; 

16 C GO TO THE OPERATOR'S CONSOLE AND STRIKE CONTROL- 'A'. 

17 C TYPE IN : /VOLLEY/E. . TM 

18 C THEN STRIKE CARRIAGE RETURN. 

19 C THEREAFTER. THIS PROGRAM WILL AT REGULAR INTERVALS EMIT A MESSAGE 

20 C (TWO BYTES LONG) TO THE BACKBOARD (FILE 'NOB') AND WAIT FOR A REPLY. 

21 C IF THE REPLY TAKES LONGER THAN 400 T^CKS (EITHER TWO OR FOUR 

22 C SECONDS. DEPENDING ON 8Y8GEN OPTIONS). THE PROGRAM STOPS WAITING. 

23 C WHETHER THERE IS ANY REPLY OR NOT. TK)E PROGRAM REPORTS ON THE 

24 C 'DO' FILE EVERY 400 TICKS IF THERE WAS A REPLY TO THE LAST 
29 C MESSAGE. AND TRIES AGAIN TO TALK TO THE BACKBOARD. 

26 C THE COMMAND TO KILL THIS PROGRAM IS: /VOLLEY/K 

27 C 

28 C 

29 C THE CODE FOLLOWS: 

30 C 

31 

32 C 

33 C 

34 C 
39 C 

36 C 

37 

38 C 

39 C 

40 C 

41 C 

42 C 

43 C 

44 C 
49 

46 C 

47 C 

48 C 

49 C 

90 C 

91 C 

92 C 

93 

94 C 
99 

96 C 

97 

98 10 

99 
60 


INTEGER»2 0UFT(8>. IUFT(8). OUTBUF. INBUF. T1ME(8) 

OUFT IS THE OUTPUT UFT 
lUFT IS THE INPUT UFT 

OUTBUF IS THE MESSAGE EMITTED TO THE BACKBOARD 
INBUF 18 THE LAST THING GOTTEN FROM THE BACKBOARD 
TIME IS AN ARRAY USED TO GET T. 0. D. FOR LOGGING 
DATA lUFT/0. 4Z99DA. 4Z9000. 3«0. 4ZC000. 0/ 

THE INPUT UFT SPECIFIES; 

USE FILE 'NOB' 

MAKE THE SYSTEM RECOVER FROM ERR08 

(WHICH REALLY MEANS KILL THIS TASK IF ERRORS) 
USE BINARY-MODE OPERATIONS 
DO A QUICK RETURN FROM THE READ CALL 
FIND THE BUFFER SIZE AND ADDRESS IN THE READ CALL 
DATA OUFT/0. 4Z99DA. 4Z9000. 3»0. 4ZC000. 0/ 

THE OUTPUT UFT SPECIFIES; 

USE FILE 'NOB' 

SYSTEM RECOVERY FROM ERRORS 

BINARY-MODE 

QUICK-RETURN 

THE BUFFER ADDRESS AND SIZE IS IN THE WRITE CAtX 
CALL IN7LEN(. FALSE. > 

(USE 1NTEGER»2 ARGUMENTS IN UTILITY CALLS) 

CALL T1MDT4(TIME. IC.O) 

(GET THE PRESENT TIME AND DATE) 

WRITE(3. lOXTlME(I). I-l. 7) 

FORMAT( 'IVOLLEY IS ACTIVE) '. 12. ': '. 12. '. 12. '. '. 13. 

X. 12. '/'. 12. '/'. 14) 

OUTBUF-0 
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IV FORTRAN IV 


61 

C 

62 

20 

63 

C 

64 

69 

c 

66 

67 

c 

68 

69 

c 

70 

71 

c 

72 

73 

c 

74 

79 

c 

76 

77 

c 

78 

79 

c 

80 

c 

81 

c 

62 

83 

c 

84 

c 

89 

86 

c 

87 

88 
69 

no 

90 

c 

91 

200 

92 

93 

94 

210 

99 

c 

96 

300 

97 

98 

c 

99 

100 

101 

310 

102 

c 

103 

400 

104 

109 

c 

106 

107 

c 

108 

109 

410 

no 

C 

111 

C 

112 

113 

C 

114 

119 

c 


C.O 04-16-79 11:38 PAGE 2 

(PICK A NE88A0E TO SEND TO THE BACKBOARD) 

IUFT(l)-0 

TOP OF THE MAIN LOOP 
(CLEAN UP AFTER ANY ERRORS) 

QUFT(l)-0 

(DITTO) 

OUTBUF-OUTBUF-M 

(CHANGE OUTPUT MESSAGE FOR VARIETY) 

CALL READ4( IUFT( 1 ). INBUF. 2. . FALSE. ) 

(QUICK-RETURN READ) 

CALL WRITE4(0UFT(1).0UTBUF.2. .FALSE. ) 

(QUICK-RETURN WRITE) 

CALL TIMDT4(TIME, IC.O) 

(REMEMBER WHEN THE WRITE HAPPENED) 

CALL DELAY(0. 400. . FAi.SE. . . FALSE. . IC) 

(WAIT A DECENT INTERVAL FOR RESPONSE) 

IF(OUFTd). NE. 2*(0UFT(l)/2) )00 TO 400 

(JUMP IF WRITE NOT YET COMPLETED (3) ) 
IF(IUFT(l>.NE.2»(IUFT(l)/2))00 TO 300 

(JUMP IF UFT BUSY BIT STILL SET. I. E. . 

IF READ NOT YET SATISFIED) 

(IF WE FALL THROUGH. THE READ IS DONE) 

IF(OUTBUF. NE. INBUF)GO TO 200 

(IF WRONG STUFF RECEIVED. JUMP) 

(IF WE FALL THROUGH HERE. EVERYTHING IS COOL) 
WRITE(3. 110)(TIME(I). 1-1.7) 

FORMAT( ' BACKBOARD IS OKAYi '. 12. '. 12. '. 12. '. '. 13. 

X. 12. '/'. 12. 14) 

GO TO 20 

(ITERATE) 

WRITE(3.210)(TIME(I). 1-1. 7) 

FORMAT( ' REPLY IS GARBLED; '. 12. '. 12. '. 12. '. '. 13. 

X. 12. 12. '/'. 14) 

GO TO 20 

(ITERATE) 

CALL TERMINO(IUFT) 

(BLOT OUT THE OUTSTANDING READ) 

WRITE(3. 310)OiME(I). 1-1.7) 

FORMAT( ' BACKBOARD DOES NOT REPLY; 12. '. 12. '. 12. '. '. 13. 

X. 12. 12. 14) 

GO TO 20 

(ITERATE) 

CALL TERMINS(OUFT) 

(CLEAN UP FAILED WRITE) 

CALL TERMINS(IUFT) 

(CLEAN UP AFTER READ. REGARDLESS OF RESULT) 

WRITE(3. 410)(T1ME(I). 1-1.7) 

FORMAT(' WRITE FAILED - BACKBOARD STATE UNKNOWN) '. 

12. '. 12. '. 12. '. 13. X, 12. '/'. 12. '/'. 14) 

IF WE EVER GET HERE. THE PROBLEMS ARE ON THE 
MODCOMP SIDE OF THE CABLE PLANT. IN THE BIU. THE 
SYMBIONT. OR THE MODCOMP HARDWARE. 


GO TO 20 
END 


(ITERATE) 
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